1

Grunderna i avenue.quark

Det finns många som vill använda webben till att publicera den information som de skapat i QuarkXPress™-format och därför finns det många sätt att göra det. Det mest effektiva sättet är att separera innehållet i sådana QuarkXPress-dokument från själva dokumentet och sedan lagra det innehållet i ett strukturerat format såsom XML. Du kan då använda innehållet igen, inte bara på webben utan även i andra format såsom tryck, cd-format, ja vad du vill.

Syftet med programmet avenue.quark™ är att göra det enkelt för dig att extrahera QuarkXPress-innehållet och lagra det i XML-format.

Med hjälp av avenue.quark kan du extrahera innehållet som finns i QuarkXPress-dokument och lagra det i XML-format. Du kan sedan enkelt använda innehållet igen på en rad olika sätt, inklusive på webben. Detta avsnitt beskriver i korthet processen och definitionerna. Mer detaljerade beskrivningar följer i senare avsnitt.

Innehållet är den information som gör dokumenten värdefulla. Innehållet i en tidskrift kan t ex vara artiklar, fotografier, intervjuer och grafik.

Innehåll kan också definieras enligt vad som inte finns. Sidhuvud, sidfot eller en anteckning av typ "forts. på sidan x" anses exempelvis i allmänhet inte vara en del av en tidskrifts innehåll. De är istället en del av tidskriftens presentation, dvs aspekter av tidskriften som bara är önskvärda när tidskriften presenteras i tryckt format. Presentationen kan ändras beroende på i vilket medium informationen publiceras, men innehållet förblir i allmänhet detsamma.

Med avenue.quark kan du åtskilja innehåll från presentation genom att extrahera innehållet som finns i QuarkXPress-dokumenten och lagra det i XML-format. Du kan sedan återanvända det innehållet i kombination med olika presentationer ­ i tryck, på webben, på CD-ROM-skiva osv. Du behöver då bara justera presentationen för varje inställning.

XML är en förkortning av Extensible Markup Language. XML ger dig en metod att ange innehållets struktur och att benämna de olika delarna i det innehållet på ett meningsfullt sätt.

Benämna innehåll

Varför behöver vi benämna innehåll? Det har att göra med att även om vi kan titta på en tidskrift och veta att en viss textrad är en rubrik är sådana distinktioner inte så enkla för en dator. Med hjälp av XML kan du "formatkoda" information på ett sådant sätt att datorer kan förstå det. När en dator förstår att en viss textrad är en rubrik kan den automatiskt formatera den raden som en rubrik.

Om du vill benämna en innehållsbit i XML infogar du en start-XML-formatkod före innehållet och en slut-XML-formatkod efter innehållet så här:

Som du kan se består en startformatkod av ett elementnamn mellan < och >. En slutformatkod ser likadan ut förutom att den har ett / efter <. Här har vi formatkodat texten "Internet växer med 400 %" som en rubrik genom att placera den mellan start- och slutformatkoder av typen <rubrik>.

Identifiera strukturen

Vi vet att en nyhetsartikel vanligtvis består av en rubrik, signaturen, själva texten och en del foton eller diagram med bildtext. Datorer kan dock inte visa innehållet så förrän du talar om det för dem.

Med XML kan du beskriva dokumentens struktur med DTDer eller dokumenttypsdefinitioner. En DTD anger att information i ett dokument ska använda en viss uppsättning med formatkoder och följa en viss uppsättning med strukturregler. En DTD för en nyhetsartikel kan t ex ange att:

• Varje artikel måste ha exakt en <rubrik>.
• Varje artikel kan ha, men behöver inte ha, en <signatur>.
• Varje artikel måste ha minst ett <stycke>.
• Varje artikel kan ha noll eller fler <illustration>-element.
• Varje illustration måste omedelbart följas av exakt en <bildtext>.

Genom att konsekvent följa reglerna för en DTD kan en organisation garantera att dess dokument alltid struktureras på ett förutsägbart och konsekvent sätt. Detta gör det mycket lättare för organisationer att flytta innehåll från ett medium till ett annat, exempelvis från tryck till webben eller tvärtom.

Avenue.quark kräver att du använder DTDer. För information om hur du skapar och anpassar DTDer, se "Arbeta med DTDer" och "Branschstandard-DTDer" i detta kapitel.

Ett "neutralt" format

XML är ett "neutralt" format eftersom det inte innehåller någon formateringsinformation. Det kan därför användas med en rad olika program som i sin tur kan använda olika sorters formatering när innehållet presenteras via olika sorters media.

För en mer detaljerad diskussion av XML, se "Förstå XML" i detta kapitel.

När du har extraherat innehållet som finns i ett QuarkXPress-dokument kan du använda det på en rad olika sätt. Du kan t ex dynamiskt översätta XML-formatkodat innehåll till HTML-format och "servera" det på webben. Denna metod att konvertera QuarkXPress-innehåll till HTML är överlägsen enkel HTML-export eftersom du lätt kan formatera, omformatera och omorganisera innehållet.

Nu när du har en allmän uppfattning om vad avenue.quark är och hur det fungerar ska vi undersöka den underliggande strukturen och vi börjar med XML.

XML (Extensible Markup Language) är en metod som används för att ange en struktur för dokument och benämna specifika bitar i innehållet med formatkoder. Med hjälp av XMLs strukturkontroller kan du försäkra dig om att dokumentets alla nödvändiga delar finns med och att de kommer i rätt ordning. Benämning av innehåll gör det enkelt för andra program att använda eller visa det innehållet.

Innan vi undersöker hur XML klarar av allt detta vill vi dock utnyttja tillfället att tala om varför det är nödvändigt.

XML har utvecklats från ett äldre och mer komplicerat uppmärkningsspråk som heter SGML (Standard Generalized Markup Language). XML skapades i syfte att lösa en rad olika relaterade problem; en del av dem löstes från början med SGML medan andra var unika.

Allokera struktur för och etiketter i informationen

XML kallas ibland för ett "metaspråk" eftersom du kan definiera anpassade uppmärkningsspråk för specifika användningsområden med hjälp av detta språk. Du gör detta genom att skapa en DTD (dokumenttypsdefinition). En DTD anger vilken typ av information som kan ingå i ett dokument, hur de olika delarna av dokumentet bör formatkodas (benämnas), de olika delarnas ordningsföljd, samt hur många av varje del som tillåtes. Ett dokument anses vara "giltigt" enligt en viss DTD, men bara om det följer reglerna för den DTDn.

Med DTDer kan du påtvinga dokumenten en struktur. Om du känner till ett dokuments DTD vet du vilken typ av information du kan förvänta dig när du öppnar det dokumentet. DTDer gör det dessutom lätt för datorer att behandla informationen i XML-dokument; om en dator kan "förstå" en DTD kan den "förstå" informationen i alla XML-dokument som följer den DTDn. Genom att ha vetskap om ett dokuments DTD kan ett datorprogram exempelvis låta dig söka igenom varje förekomst av en viss typ av information (såsom företagsnamn) i det dokumentet eller framställa en HTML-sida som visar alla förekomster av den typen av information (t ex en lista med företagsnamn).

Specialiserade DTDer har redan utvecklats för kemi, matematik, teknisk dokumentation och t o m skönlitterärt material. Möjliga användningsområden inkluderar arbetsflödeskontroll, programspecifikation och nästan alla andra områden som involverar utbyte av strukturerad information.

Bara en liten notis: till skillnad från SGML kan du med XML skapa "välutformade" dokument, dvs dokument som följer reglerna för XML, men som inte följer en viss DTD. Om du inte har en standard kan det däremot vara svårt att upprätthålla enhetlighet mellan olika dokument och av denna anledning kräver avenue.quark att du använder DTDer.

Vad är egentligen HTML?

HTML har visat sig vara ett kraftfullt och allsidigt format när det gäller att visa information på webben. Formatet har dock två stora nackdelar: det beskriver enbart formatering av data, inte dess betydelse, och du kan inte skapa nya HTML-formatkoder.

XML löser båda dessa problem. Om du använder XML till att benämna data i ett XML-dokument kan du sedan basera HTML-formateringen på de etiketterna. Låt oss säga att du har ett XML-dokument som består av en lista med företag och en del information om vart och ett av de företagen. Om du vill omvandla denna lista till en HTML-webbsida där varje företagsnamn skrivs med fet stil behöver du bara använda en XML-till-HTML-konverterare och instruera konverteraren att använda fet stil på varje rad som är formatkodad med <företagsnamn>. Detta gör att du inte längre behöver gå igenom och formatera varje företags namn och adress manuellt, vilket i sin tur leder till möjligheter till ofantliga tidsbesparingar för dem som skapar webbplatser.

Informationsutbyte

Eftersom datorprogram har utvecklats av många olika personer och organisationer för många olika ändamål lagrar de information i många olika format. Två företag kan t ex lagra sin kundinformation i två helt olika format, även om kundinformation som företagen har i sina arkiv (namn, adress, telefonnummer osv) i grunden är identisk.

XML löser denna typ av problem genom att tillhandahålla ett standardiserat, ej patenterat format för överföring av information mellan olika program. XML utvecklades, förbättrades och godkändes av en grupp med yrkesmän och -kvinnor från olika branscher som arbetar tillsammans som en del av W3C (World Wide Web Consortium). Specifikationen finns tillgänglig för alla som vill använda den (se www.w3.org), och många organisationer och branscher använder den redan.

Om två företag samtycker till att använda programvara som kan konvertera deras uppgifter till XML med en DTD som de kommer överens om, kan de utbyta dessa uppgifter när som helst, utan någon risk för dataförlust p g a format som inte är kompatibla. För mer information om DTDer och informationsutbyte, se "Branschstandard-DTDer" i detta kapitel.

Se "Arbeta med XML" i detta kapitel för en mer detaljerad diskussion om XML.

Ett XML-dokument innehåller strukturerade data som har brutits ner i "element" som vart och ett beskrivs med XML-formatkoder.

Ett XML-element innehåller en informationsdetalj såsom ett företagsnamn, en rubrik eller ett beställningsnummer. Du skapar ett element genom att placera en informationsbit mellan två XML-formatkoder: en startformatkod som innehåller elementets namn mellan en mindre än-symbol och en större än-symbol, och en slutformatkod som ser likadan ut förutom att den har ett snedstreck (/) i elementnamnet. Ett formatkodat "namn"-element kan t ex se ut så här:

Det är viktigt att förstå skillnaden mellan ett XML-element och en XML-formatkod. En XML-formatkod är helt enkelt bara den etikett som bifogas med en informationsdetalj; ett XML-element inkluderar både informationsdetaljen och de formatkoder som omger den.

Med XML-formatkoder kan du beskriva och lägga till struktur i sådana data som de omger. Följande inledningsstycke formatkodas exempelvis med en <introduktion>-formatkod:

Inom <introduktion>-elementet kan du formatkoda andra underelement om du vill lägga till mer struktur i ditt dokument:

<introduktion>

<namn>Frank Lloyd Wright</namn> var en av Amerikas främsta och mest berömda <yrke>arkitekter</yrke>. Här är hans livshistoria.

Syntaxen är viktig för XML-formatkoder. Till skillnad från HTML-formatkoder skiljer dessa mellan versaler och gemener; en <Namn>-formatkod skiljer sig från en <namn>-formatkod, som skiljer sig från en <NAMN>-formatkod. Varje XML-formatkodsnamn måste inledas med en bokstav eller ett understrykningstecken (_); efterföljande tecken i namnet kan vara bokstäver, understrykningar, siffror, bindestreck och punkter, men inte blanksteg eller tabbtecken. XML-formatkodsnamnet <_.dir> är ett korrekt bildat formatkodsnamn, men namnen <_ dir> och <.dir> är det inte. Formatkodsnamnet <_ dir> är fel eftersom det innehåller tomrum (tabulator eller blanksteg) efter understrykningen. Formatkodsnamnet <.dir> är fel eftersom det inleds med en punkt i stället för en understrykning eller bokstav.

Det är praktiskt att vara medveten om skillnaden mellan "element" och "elementtyper". Du kan tänka på en elementtyp som ett speciellt formatkodsnamn som kan användas i data; ett element är en datadetalj och de formatkoder som omger det. Ett dokument som t ex innehåller en lista med namn och adresser kanske bara har två elementtyper, <namn> och <adress>, men hundratals element som använder de formatkoderna.

Låt oss säga att du arbetar med element som formatkodats <bil> och att du vill kunna ange ytterligare information om varje <bil>-element som du skapar. Låt oss säga att du vill kunna beteckna ett visst <bil>-element inte bara som en bil, men en snabb, röd och dyr bil.

Det finns flera sätt att göra det. Ett sätt innebär att du skapar ytterligare elementtyper så här:

Ett annat (och kanske "renare") sätt att göra detta är med en XML-funktion som kallas attribut. Attribut designas i syfte att ange information om ett element. De inkluderas inom ett elements startformatkod, så det finns aldrig något tvivel om vilket element de tillhör.

Ett attribut består av ett attributnamn, följt av ett likhetstecken, följt av ett attributvärde mellan citationstecken. Följande enkla element använder tre attribut för att tillhandahålla samma information som exemplet ovan:

Attribut är användbara av flera orsaker. De gör det exempelvis lätt att söka igenom ett dokument och generera en lista med alla <bil>-element som innehåller värdet "dyr" i kostnadsattributet. De kan också vara användbara i samband med tomma element (se nästa avsnitt för information).

Tomma element inkluderar en startformatkod och en slutformatkod som inte omger några data, så här:

Eftersom tomma element inte har något innehåll mellan sina formatkoder, kombineras ofta start- och slutformatkoder så här:

När du vill referera till URL eller externt lagrade filer kan du använda attribut tillsammans med tomma element. Följande tomma element skulle t ex kunna användas (med en lämplig XML-tolk) för att visa en bild av en bil:

Observera att om du bara lägger till ett attribut som heter "URL" i ett element garanterar inte det att URL kan nås när XML-filen behandlas. Programmet som behandlar filen måste veta vad som ska göras med URL-attributet.

Du kan inkludera kommentarer i en XML-fil på samma sätt som i HTML. Kommentarer omges med <!-- och --> och ignoreras nästan helt och hållet av XML-behandlare. Så när du exempelvis ska infoga en kommentar om status för ett <adress>-element kan du göra följande:

I HTML används kommentarer i allmänhet för specialkommandon i webbläsare och andra HTML-behandlare. I en ansträngning att begränsa XML-kommentarer till enbart kommentarer har XML-specifikationens författare inkluderat en metod att infoga anpassade kommandon i XML-filer och DTDer. Sådana anpassade kommandon, som kallas behandlingsinstruktioner (eller "Processing Instructions (PI)"), bifogas helt enkelt mellan <? och ?>. De inleds med ett programnamn, därefter ett blanksteg och all den information som kan vara av intresse för det namngivna programmet. Behandlingsinstruktioner kan användas var som helst där kommentarer kan visas.

Varje XML-dokument kan och bör inledas med en XML-deklaration. Som behandlingsinstruktion bifogas en XML-deklaration mellan <? och ?>. Här är ett exempel på en XML-deklaration:

Attributet "version" deklarerar att detta dokument följer reglerna i XML 1.0. Det "fristående" (standalone-) attributet indikerar att alla uppmärkningsdeklarationer som behövs för att behandla detta XML-dokument finns med i dokumentet.

Ett entitetsanrop är ett ord som fungerar som ett förkortat format för ett tecken, en sträng eller fil. Genom att t ex använda entitetsanropet &lt; till att representera mindre än-tecken (<) i ett XML-dokuments innehåll kan du undvika att förvirra XML-tolken (som annars felaktigt skulle läsa "<"-tecknet som början av en formatkod). För mer information om entitetsanrop, se "Entitetsanrop" i avsnittet "Arbeta med DTDer" i detta kapitel.

Innan ett XML-dokument kan anses vara välutformat kan och bör det inledas med en XML-deklaration och ha ett rotelement som innehåller alla dess andra element (<artikel> i exemplet nedan). Ett välutformat XML-dokument kräver också att varje element i dokumentet ska ha en motsvarande slutformatkod. Följande är ett exempel på ett välutformat XML-dokument:

Om XML-dokumentet inte är giltigt kan dess användning vara begränsad. Ett XML-dokument anses vara giltigt när det följer specifikationerna för en specifik DTD. För mer information om DTDer och testning av giltighet för XML-dokument, se "Förstå DTDer" i detta kapitel.

En XML-behandlare är helt enkelt ett program som läser en XML-fil och gör någonting med den. Det finns olika typer av XML-behandlare. En XML-behandlare kan konvertera en XML-fil till en HTML-webbsida, en PDF-fil eller en PostScript-fil. Den kan också läsa XML-filens innehåll högt eller konvertera innehållet till blindskrift. En XML-behandlare kan t o m användas till att kopiera strukturerat XML-innehåll i en databas.

XML-tolkar

En XML-tolk känner igen XML-regler och kontrollerar huruvida ett XML-dokument är välutformat eller ej. En XML-tolk kontrollerar däremot inte nödvändigtvis om ett XML-dokument är giltigt enligt sin DTD; detta kräver en validerande XML-tolk (se nedan).

Validerande XML-tolkar

Validerande XML-tolkar jämför ett XML-dokument med en DTD och verifierar huruvida dokumentet följer DTDns regler. En bra validerande tolk ger dessutom konstruktiv feedback om eventuella problem den hittar i XML-filen. För mer information om XML-tolkar, se "Förstå DTDer" i detta kapitel.

För en snabbreferens till XML-funktioner och -konventioner, se bilaga A, "XML Snabbreferens" i kapitel 7, "Bilagor".

En DTD (dokumenttypsdefinition) anger vilka element en XML-fil kan innehålla och hur de elementen måste struktureras. XML-dokument behöver inte nödvändigtvis ha en motsvarande DTD; under förutsättning att en XML-fil följer grundläggande XML-syntax anses den vara "välutformad" och kan läsas av ett XML-kunnigt program. Men det är bara om en XML-fil följer en viss DTD som den kan anses vara "giltig".

DTDer är viktiga eftersom de tillhandahåller en tillförlitlig, väldokumenterad struktur för XML-dokument. Utan DTDer kan två organisationer som arbetar tillsammans bestämma sig för att strukturera och formatkoda sina XML-dokument på helt olika sätt och därmed skulle deras dataarkiv förbli inkompatibla även efter det att båda har gjort övergången till XML. Om båda organisationerna har samma DTD ­ kanske en DTD som de har utvecklat tillsammans eller en DTD som har blivit standard inom deras bransch ­ gäller däremot att de kan utbyta information på ett enkelt och förutsägbart sätt.

Det finns två sorters DTDer: externa och interna.

Tekniskt sett består en DTD av listan med uppmärkningsdeklarationer (elementdeklarationer, attributdeklarationer, entiteter, notationer, behandlingsinstruktioner och kommentarer) som en DOCTYPE-deklaration hänvisar till. Vad detta dokument kallar "externa DTDer" och "interna DTDer" är inte tekniskt fullständiga DTDer; det är dock bekvämt och ganska vanligt att kalla dem så.

Externa DTDer

En extern DTD (eller extern delgrupp) är en fil som innehåller en lista med uppmärkningsdeklarationer. Det är lätt att dela externa DTDer mellan XML-dokument och organisationer. Om du vill använda en extern DTD i en XML-fil refererar du helt enkelt till den i början av XML-filen så här:

Interna DTDer

En intern DTD (eller intern delgrupp) inkluderas faktiskt i den XML-fil som den beskriver. Om du vill använda en intern DTD i en XML-fil lägger du helt enkelt till den i början av XML-filen så här:

Om ett dokument använder en extern DTD (eller någon annan typ av extern entitet), måste "standalone"-attributet på den första raden anges som "no." För mer information, se "Använd entitetsanrop" i detta avsnitt.

Kombinera interna och externa DTDer

I ett visst XML-dokument kan du ange en extern DTD och sedan lägga till eller åsidosätta den DTDn med en intern DTD. Så här kan ett sådant XML-dokument se ut.

Det mest troliga är att du inte bara sätter dig ner och börjar skriva en DTD; det krävs nämligen en hel del planering om du vill göra det rätt.

Innan du påbörjar processen att skapa din egen DTD kanske du vill överväga möjligheten att använda en branschstandard-DTD. För mer information om detta alternativ, se "Branschstandard-DTDer" i detta kapitel.

Ett bra sätt att komma igång är att fundera ut exakt vad du vill att din DTD ska göra. Först bör du komma underfund med vilka element du vill använda. Om du vill använda sådana element som <adress>, ska du tänka över huruvida du vill dela in dessa element i underelement ännu mer, såsom <gatuadress>, <våningsnummer>, <ort>, <län> och <postnummer>. (Tänk noga igenom sådana ytterligare uppdelningar om du tror att du kanske kommer att överföra innehållet i dina XML-filer till en databas någon gång i framtiden.)

Ja nu har vi pratat färdigt om den enkla delen. Du behöver nu utarbeta vilka förhållanden som finns mellan alla dessa element. En DTD kan ange vilka element som tillåtes, vilken ordningsföljd som gäller och vilka (och hur många) underelement de kan innehålla. Den kan ange vilka andra element som kan innehålla ett givet element och den kan ange huruvida ett givet element måste innehålla data eller ej.

Eliotte Rusty Harold rekommenderar i XML: Extensible Markup Language att du använder en tabell som hjälper dig att utarbeta förhållandena mellan de olika elementen i DTDn. Tabellen bör ha följande kolumner (data i kolumnen tillhandahålles endast som exempel):

Varje rad i tabellen bör representera ett element som du vill använda i din DTD.

På samma sätt som gäller för en XML-fil består en DTD av oformaterad text. En XML-fil kan använda ingen DTD alls, en extern DTD, en intern DTD eller både en extern och en intern DTD.

Oavsett vilken typ av DTD ett XML-dokument använder måste den referera till eller inkludera den DTDn i sin inledning (öppningsavsnitt), precis efter XML-deklarationen och före själva texten i XML-dokumentet. DTD-avsnittet inleds med "<!DOCTYPE rotnamn [" och avslutas med "]>". Här illustreras t ex ett fullständigt XML-dokument som innehåller en fullständig DTD (med fet stil):

Låt oss bryta ner det här i mer detalj:

• Rotnamnet (ordet efter <!DOCTYPE) anger XML-filens rotelementtyp.
• Hakparentes indikerar och omger den interna DTDn.
• "<!ELEMENT meddelande ANY>" definierar en elementtyp som heter "meddelande". "!ELEMENT" betyder "Följande är en elementtypsdeklaration". Sedan kommer namnet på elementet ("meddelandet") och information om vad detta element kan innehålla (i detta fall "ANY" vilket betyder både text- och ytterligare element).

Som du kan se anger varje elementtypsdefinition både elementets namn och den typ av data som elementet kan innehålla. Om du skulle vilja ändra elementtypsdefinitionen för <meddelande> så att den innehåller text och bara text (dvs inga andra element), kan du göra det genom att ändra nyckelordet "ANY" till "(#PCDATA)" så här:

Men du kommer troligtvis inte att vilja göra detta eftersom det skulle innebära att ditt dokuments rotelement bara skulle kunna innehålla analyserade teckendata (se anmärkning nedan); du skulle inte kunna lägga till fler element för att ytterligare dela upp informationen.

"PCDATA" står för "analyserade teckendata" (Parsed Character Data), dvs text som kan inkludera entitetsanrop, kommentarer och behandlingsinstruktioner.

Låt oss ta en titt på en mer realistisk DTD. Följande interna DTD definierar en struktur för en katalog med filialkontor:

Observera att vi har infogat en kommentar som indikerar att <filialkontorskatalog> är rotelementet i DTDn. Vi gjorde detta eftersom en DTD inte uttryckligen kan designera ett rotelement. Uppgiften för raden !DOCTYPE i ett XML-dokument är tekniskt sett att ange rotelementet. Men det är bra att ange rotelement med en kommentar så att användare av den DTDn kan se vilka de är.

Vissa DTDer kan innehålla fler än ett element som kan fungera som ett rotelement. Du kan t ex skriva en DTD som innehåller definitioner för både presentationsdokument och frågedokument och sedan använda den DTDn till att skapa båda dokumenttyperna genom att helt enkelt ange <whitePaper> eller <frågor> som rotelement i XML-filerna.

Resterande rader i DTDn deklarerar element för varje kontors gatuadress, postnummer, ort, land, telefonnummer, faxnummer och e-postadress.

Ovanstående DTD kan fungera bra för dig men den utnyttjar inte riktigt de fördelar som finns i XML-egenskaperna. Den anger t ex inget sätt att indikera vilka adresselement som tillhör vilka kontor och den anger inte någon speciell ordningsföljd för informationen. Det innebär att du skulle kunna skapa ett dokument som visar alla de olika orterna, gatorna, telefonnumren och så vidare i slumpmässig ordning och det skulle ändå vara giltigt enligt denna DTD.

Om du vill ge DTDn en meningsfull struktur behöver du en metod att sätta ihop alla komponentelementen för varje lista och placera dem i en viss ordningsföljd. Ett sätt att göra detta är att skapa ett behållarelement som ska innehålla den relevanta informationen för ett kontor (vi kan kalla det <filialkontor>), och sedan ange vilka delelement som behållarelementet måste bestå av och i vilken ordningsföljd de måste komma. Vi kan göra allt detta genom att lägga till en rad i DTD (med fet stil):

Vad detta nya element säger är att "om dokumentet innehåller ett element som heter <filialkontor>, måste detta element innehålla exakt ett av följande element, i den här ordningen och ingenting annat".

Vad händer om några av filialkontoren har fler än en rad i sin gatuadress? Du kan tillåta en eller flera förekomster av valfritt element i en lista med delelement genom att lägga till ett + omedelbart efter elementets namn. Om du t ex vill tillåta ett eller flera <gatuadress>-element i vårt <filialkontor>-element kan vi göra så här:

Vad händer om vissa filialkontor inte har en faxmaskin? Och vad händer om en del av dem har fler än en? När du vill ange noll eller fler förekomster av ett element lägger du till en * omedelbart efter elementnamnet så här:

Och vad händer om vissa filialkontor finns i ett land där de inte har någon motsvarighet till det vi kallar postnummer? Om du vill ange att noll eller en förekomst av ett givet element kan uppstå lägger du till ett frågetecken omedelbart efter elementnamnet så här:

Det som kallas ett "län" i Sverige kan ha ett annat namn i andra länder. Kanada är t ex indelat i provinser. Om du har kontor i både Sverige och Kanada kanske du vill tillhandahålla en möjlighet att använda ett <län>-element eller ett <provins>-element. Det kan du göra genom att placera två alternativ inom parentes, åtskilda med ett |-tecken så här:

Till sist kan vi försäkra oss om att en <filialkontorskatalog> inte består av något annat än <filialkontor>-listor genom att ändra definitionen för <filialkontorskatalog> från ANY till (filialkontor*). Här är vår slutgiltiga produkt:

En kort repetition:

Specialsymbolerna kan användas i samband med parentes när du vill skapa komplexa elementtypsdeklarationer såsom följande DTD som är avsedd att visa daglig kontaktinformation:

Den person som representeras i denna lista kan vilken dag som helst befinna sig på kontoret, hemma eller borta på en affärsresa. Varje <kontaktinfo>-element kan alltså inkludera en av följande listor med information, med delelement i den ordning som anges här:

• Datum, verksamhetens telefonnummer, noll eller flera av verksamhetens faxnummer, e-postadressen och noll eller ett meddelande.
• Datum, ett eller flera hemtelefonnummer och/eller personsökarnummer, noll eller fler hemfaxnummer, e-postadress och noll eller ett meddelande.
• Datum, ett eller flera resetelefonnummer och/eller personsökarnummer, noll eller flera resefaxnummer, e-postadress och noll eller ett meddelande.

Du kanske vill skriva dina XML-dokument på ett sådant sätt att de enkelt kan översättas till HTML-format. Om så är fallet kanske du vill inkludera sådana formatkoder som <BR> och <HR> i din XML-fil, med avsikt att översätta dem ord för ord till HTML-filen.

I XML kan du inte riktigt göra det på det viset eftersom varje element måste ha en slutformatkod. Du kan dock skapa vad som kallas tomma (EMPTY) formatkoder och låta en XML-till-HTML-konverterare oroa sig för att översätta dem till rätt utmatningsformatkoder. Du kan t ex tillåta skapandet av <HR>-formatkoder genom att inkludera följande rad i DTDn:

Om du vill använda denna formatkod kan du infoga en rad som ser ut så här i din XML-fil:

Du kan inte inkludera den som "<HR>" eftersom varje XML-formatkod antingen måste ha en slutformatkod eller avslutas med ett framåt snedstreck, men det är OK; en XML-till-HTML-konverterare bör konvertera <HR/> till en <HR>.

EMPTY formatkoder används ofta till att innehålla bilder. URL för bilddata lagras i ett av attributten för den EMPTY formatkoden. För mer information om attribut, se "Definiera attribut" i detta avsnitt.

Ett teckenanrop är ett sätt att representera Unicode-tecken i analyserade teckendata. Syntax för teckenanrop är som följer:

Om du t ex vill infoga valutasymbolen för euron före värdet 500 i ett <belopp>-element kan du göra så här (teckenanropet skrivs med fet stil):

Det är XML-behandlarens uppgift att ersätta de tillämpliga Unicode-tecknen med teckenentitetsanrop vid utmatningen.

Ett entitetsanrop är en liten mängd text som representerar något annat, såsom tecken, textsträng, externt lagrad XML-fil eller binärfil (såsom en bild- eller ljudfil). Det finns fem sorters entitetsanrop:

• Analyserade interna entitetsanrop, när du vill representera textsträngar som ofta används
• Analyserade externa entitetsanrop, när du vill referera till externt lagrade textfiler som innehåller analyserbara data
• Icke analyserade externa entitetsanrop, används ofta när du vill referera till binärfiler såsom bilder, kalkylblad och ljud
• Interna parameterentitetsanrop, när du vill representera uppmärkningsdeklarationer som ofta används inom DTDer (analyseras alltid)
• Externa parameterentitetsanrop, när du vill referera till externt lagrade textfiler som innehåller analyserbara data inifrån DTDer (analyseras alltid)

Dessa entitetsanropstyper beskrivs i detalj nedan.

Vad är skillnaden mellan en entitet och ett entitetsanrop? Ett entitetsanrop är det förkortade format du infogar i ett XML-dokument när du vill representera en entitet. En entitet är det innehåll som ersätter entitetsanropet när XML behandlas.

Analyserade interna entitetsanrop

Ett analyserat internt entitetsanrop är i grunden ett förkortat format för en sträng med tecken som du avser att ofta använda gång på gång inom ett visst XML-dokument. Följande format deklarerar ett analyserat internt entitetsanrop i en DTD:

Låt oss säga att du bygger ett XML-dokument som innehåller en lista med anställda och en del information om var och en av dem. Varje anställds uppgift måste innehålla frasen "Antal år på företaget:" följt av ett värde. I stället för att skriva in frasen flera gånger manuellt kan du skapa ett analyserat internt entitetsanrop för den frasen som en del av dokumentets DTD, så här:

När vi vill använda det analyserade interna entitetsanropet "år" i XML-dokumentet kan vi göra så här:

När detta <anställd>-element behandlas expanderar XML-behandlaren det analyserade interna entitetsanropet vilket resulterar i följande XML:

Det finns fem, tillgängliga, fördefinierade analyserade interna entitetsanrop i XML. Till skillnad från alla andra analyserade interna entitetsanrop är dessa en del av XML-specifikationen och behöver inte deklareras.

Låt oss säga att du behöver använda ett större än-tecken (>) i XML-dokumentets innehåll. Som du vet indikerar större än-tecknet slutet av en formatkod i XML. Om du vill undvika förvirring med XML-behandlaren kan du skriva "&gt;" i stället för större än-tecknet där det förekommer. Om du t ex vill uttrycka "helheten är > summan av dess delar" i en XML-fil, kan du göra så här:

Det finns tre begränsningar när du använder analyserade interna entitetsanrop:

• Du måste deklarera ett analyserat internt entitetsanrop innan du använder det (med undantag av de fem som visas ovan).
• Du kan använda ett analyserat internt entitetsanrop i elementinnehåll och i attributvärden.
• Du kan använda ett analyserat internt entitetsanrop inuti ett annat analyserat internt entitetsanrop, men bara om detta inte leder till en runtgående referens. Det skulle t ex vara förbjudet att använda det analyserade interna entitetsanropet A i det analyserade interna entitetsanropet B om det analyserade interna entitetsanropet B används i det analyserade interna entitetsanropet A.

Analyserade externa entitetsanrop

Med ett analyserat externt entitetsanrop kan du inkludera innehåll som lagrats i en externt placerad textfil. Analyserade externa entitetsanrop bör deklareras i DTD på ett av följande sätt:

I det första exemplet kan du använda URL för en viss fil. I det andra exemplet kan du använda namnet på en resurs som i sin tur kan peka på en URL; den URL som följer är en "reserv"-URL som bara ska användas om namnet inte kan matchas.

Analyserade externa entitetsanrop kan användas när du vill att XML-filer ska dela innehåll. Här är t ex ett fullständigt exempel på ett XML-dokument i vilket innehållet lagras i en textfil som heter "minfil.txt" på Quarks™ webbplats:

Detta är praktiskt eftersom du dessutom kan använda innehållet i "minfil.txt" i andra XML-filer.

Om ett dokument använder externa entitetsanrop bör du ange att det "standalone"-attributet ("fristående") i XML-deklarationen ska vara "no".

Icke analyserade externa entitetsanrop

Vad händer om du vill referera en bild, ett kalkylblad, en ljudfil, HTML-fil eller annan icke-XML-fil i ett XML-dokument? Du kan inte använda ett analyserat externt entitetsanrop eftersom XML-behandlaren kommer att försöka analysera din binärfil, vilket leder till fel.

Du kan undvika detta problem genom att ange en notation i slutet av det externa entitetsanropet. En notation instruerar helt enkelt XML-behandlaren att inte analysera målfilen och indikerar vilken typ av fil det är. Här följer formatet för en deklaration av en notation i en DTD:

Om du t ex vill skapa en förbindelse mellan JPEG-filer och Adobe® Photoshop® kan du lägga till en notation som den här i DTDn:

Om du vill använda en notation i en extern entitetsanropsdeklaration använder du följande syntax:

Om du t ex vill skapa en entitet som heter "minBild" som pekar på en URL som innehåller en JPEG-fil kan du använda följande formatkod:

Du kan dessutom använda PUBLIC-syntaxen med notationer och först ange ett namn för offentlig notation och sedan en reservnotations-URL:

Andra sätt att hänvisa till externa filer: icke analyserade entitetsanrop är inte det enda sättet att referera externa filer i XML-filer utan att ange att de måste analyseras. Du kan även lagra URL för en sådan fil som ett normalt element eller attributinnehåll. Det första exemplet nedan hänvisar till URL för en bildfil som elementinnehåll och det andra exemplet hänvisar till samma URL som attributinnehåll:

Du väljer själv om du vill använda icke analyserade entiteter, element eller attribut när du hänvisar till icke-XML-filer. Alla dessa metoder fungerar lika bra, under förutsättning att programmet som behandlar XML vet att URL är URL.

Interna parameterentitetsanrop

Om du vill skapa ett entitetsanrop som bara används inom en viss DTD måste du skapa ett parameterentitetsanrop. Ett internt parameterentitetsanrop liknar på många sätt ett analyserat internt entitetsanrop, förutom att det börjar med en %-symbol i stället för en &-symbol, både i dess deklaration och när du använder det:

Du kan använda interna parameterentitetsanrop i en DTD:s externa delmängd på samma sätt som du använder analyserade interna entiteter i ett XML-dokument. Här använder vi t ex ett internt parameterentitetsanrop till att skapa ett förkortat format som hänvisar till en innehållsmodell som beskriver en persons namn:

Detta är användbart eftersom du enkelt kan ändra definitionen för alla sorters namn samtidigt. Därför gäller att om du exempelvis bestämde dig för att du även ville lagra alla arbetsgivares, anställdas och kunders mellannamn behöver du bara ändra den interna parameterentitetsdeklarationen ovan till:

Observera att denna typ av internt parameterentitetsanrop bara kan användas i en DTDs externa delmängd.

Externa parameterentitetsanrop

Ett externt parameterentitetsanrop påminner mycket om ett analyserat externt entitetsanrop, förutom att det börjar med en %-symbol i stället för en &-symbol, både i dess deklaration och när du använder det. Följande två rader (från ett XML-dokuments interna delmängd) skapar först ett entitetsanrop som pekar på en extern DTD som heter "standardHeader.dtd" och inkluderar sedan den externa DTD:n i XML-filen:

För mer information om hur du kan använda det här, se "Använd offentliga DTDer" i detta avsnitt.

Parameterentitetsanrop kan bara användas inom en DTD.

Interna och externa parameterentitetsanrop kan användas tillsammans. Du kan t ex använda interna parameterentitetsanrop i den interna delmängden till att hänvisa till entiteter som definieras i den externa delmängden. Detta är praktiskt eftersom du då kan ändra definitionen för en entitet utan att behöva ändra den interna delmängden för XML-filer som använder entiteten. Därför kan du t ex inkludera följande deklaration i en textfil som heter "entitetsfil.txt":

Inkludera sedan följande i den interna delmängden med XML-dokument:

På det här sättet kan du ändra definitionen för entitetsanropet namnentitet i valfritt antal XML-dokument genom att ändra den i filen "entitetsfil.txt".

Förutom att bestå av innehåll kan element även ha attribut (se "Förstå XML" i detta kapitel). Det finns oenighet om attributens roll, men i denna diskussion kommer vi att förutsätta att ett attribut bör innehålla information om ett element som är viktigt för XML-behandlaren, men som inte är en del av innehållet i själva XML-filen.

Antag att du använder XML till att upprätthålla en boklista som ska visas på en webbplats. Listan kan visas på två olika sätt: som en fullständig lista eller som en lista med alla de böcker som har lagts till i listan under de senaste 10 dagarna. Innan detta kan fungera behöver XML-dokumentet indikera det datum då varje bok införs.

Du kan lägga till en underliggande formatkod av typ <införningsdatum> i definitionen för <bok>-formatkoden, men det datum då en viss bok införs i ditt system är ju egentligen inte information om själva boken, så du kanske istället väljer att skapa ett attribut som heter "införningsdatum".

Syntax för attributdeklarationer är som följer:

Om du vill ge <bok>-elementet ett attribut av typen "införningsdatum" med ett standardvärde som är "2000/01/01/" lägger vi alltså till följande rad i DTDn:

Om du sedan vill använda detta attribut i ett <bok>-element kan vi helt enkelt använda ett attributvärdepar så här:

Detta attribut kommer att ge XML-behandlaren den information som behövs för att visa böcker baserat på deras införningsdatum.

Obligatoriska (Required), underförstådda (Implied) och låsta (Fixed) attribut

Varje attribut kan vara obligatoriskt, underförstått eller låst. Ett obligatoriskt attributstandardvärde anger att elementet måste innehålla detta attribut. Följande attributdeklaration anger t ex att varje <bok>-element måste ha ett "införningsdatum"-attribut:

Ett underförstått attributstandardvärde indikerar att elementet kanske inte innehåller detta attribut, men att det är upp till XML-författaren att bestämma detta. Följande attributdeklaration anger t ex att varje <bok> kanske eller kanske inte innehåller ett attribut av typen "införningsdatum":

Ett låst attributvärde indikerar att attributet måste innehålla ett exakt värde för varje element. Följande attributdeklaration anger t ex att varje <bok> måste ha ett "införningsdatum"-värde som är lika med "1998/11/11":

I detta exempel antar XML-behandlaren att varje <bok>-element har ett "införningsdatum"-attribut som är inställt till "1998/11/11", även om attributet utesluts.

Om en attributdeklaration har ett standardvärde, men inte anger #REQUIRED, #IMPLIED eller #FIXED, tar XML-behandlaren standardvärdet för attributet varje gång attributet utesluts.

Attributtyper

Nyckelordet CDATA i vårt exempel på attributdeklaration indikerar att vi vill att detta attribut ska innehålla teckendata. CDATA är dock bara ett alternativ för attributtyp. Den fullständiga listan följer:

• Ett CDATA-attribut kan innehålla teckendata och entitetsanrop.
• Ett ENTITY-attribut måste innehålla namnet på en icke analyserad entitet som deklarerats i DTDn. (För mer information om entiteter, se "Använda entitetsanrop" i detta avsnitt.) Du kan t ex använda ett ENTITY-attribut som ska innehålla en URL för en bild:

• Ett ENTITIES-attribut måste innehålla namnet på en eller flera av de icke analyserade entiteter som deklarerats i DTDn. Listan med entiteter måste åtskiljas med blanksteg. Exempel:

• Ett uppräkningslistattribut kan innehålla ett enda namn från en lista med namn inom parentes. (Här innebär "namn" att alla värden i listan måste följa samma namnkonventioner som XML-element.)
• Om du vill använda ett uppräkningslistattribut lägger du helt enkelt till listan med namn i attributdeklarationen i stället för ett nyckelord. Följande rad anger t ex att "prisstatus"-attributet för <bok>-elementet bara kan innehålla "Realisation" eller "Ordinarie_pris":

• Ett ID-attribut anger att varje element måste ha ett unikt värde (om det finns något överhuvudtaget) för det attributet. Exempel:

Ett ID-attribut måste ha ett deklarerat standardvärde som är #IMPLIED eller #REQUIRED. Inget element kan ha fler än ett ID-attribut.

• Ett IDREF-attribut måste "peka på" ett annat element i XML-dokumentet som har ett ID-attributvärde. Exempel:

• Värdet för ett IDREFS-attribut består av en serie med IDREF-attribut, åtskilda med blanksteg.
• Värdet för ett NMTOKEN-attribut kan innehålla olika tecken, inklusive bokstäver, siffror, understrykning, punkter osv, men kan inte innehålla blanksteg. Följande exempel är t ex illegalt eftersom frasen "Mitt lokala namn" innehåller blanksteg:

• Ett NMTOKENS-attribut är samma sak som ett NMTOKEN-attribut, förutom att det anger att attributvärdet kan vara en lista med NMTOKEN åtskilda med blanksteg.

• Ett NOTATION-attribut måste innehålla ett eller flera XML-notationsnamn från DTDn. På så sätt kan du skapa notationer som anger bildvisnings- och filmuppspelningsprogram och sedan använder ett elementattribut för att garantera att korrekt program används för en viss del av innehållet. Exempel:

• Denna information låter det program som behandlar XML veta att det kan använda programmet Bildvisare till att öppna bildfilen och programmet Filmvisare för att öppna filmfilen.

Inget element kan ha fler än ett NOTATION-attribut.

• Ett uppräknings-NOTATION-attribut måste innehålla en lista med ett eller flera XML-notationsnamn inom parentes från DTDn. Du kan t ex skapa notationer som anger flerbildsvisnings- och filmuppspelningsprogram och sedan använda ett elementattribut för att garantera att rätt uppsättning med program används för en viss innehållsbit. Här ser du hur det kan se ut:

I stället för att skapa ett element för både bilder och filmer skapar vi här två separata element, <bild> och <film>. För vart och ett av dessa element anger DTDn två olika program som kan användas till att visa filen. Avgörandet av vilket program som ska användas görs i varje individuell <element>-formatkod i XML-texten.

Attributet xml:lang

Med attributet "xml:lang" kan du ange vilket språk som används i ett element. Detta attribut bör innehålla ett av följande:

* En språkkod bestående av två bokstäver som definierats av ISO 639 som, om du vill, följs av ett bindestreck och en deltyp (vanligtvis en landskod)

* Ett IANA-registrerat språknummer, med prefixet "i-" eller "I-"

* En användardefinierad språkkod, med prefixet "x-" eller "X-"

Observera att dessa attribut inte fördefinieras ­ du måste deklarera dem innan du använder dem.

Du indikerar vilket språk du vill ha genom att helt enkelt allokera språkets kod. Exempel: följande DTD anger ett "xml:lang"-element och elementet i XML-texten anger det engelska språket vid användning av ISO 639:

Du kan ange språkdeltyper genom att lägga till ett bindestreck efter språknamnet. Följande element anger t ex internationell engelska (används i Storbritannien), i motsats till amerikansk engelska:

Attributet xml:space

Med attributet "xml:space" kan du indikera till det program som behandlade XML-dokumentet att det bör lämna allt tomrum för ett element och dess barn som de är (om inte ett av elementets barn återställer formatkoden). Exempel: följande DTD anger ett "xml:space"-attribut och elementet i XML-texten ställer in attributet på "bevara" för elementet och dess barn:

Du kan använda formatkoden <![IGNORE[]]> när du vill instruera XML-tolken att ignorera en viss del av texten i en extern DTD. Låt oss ta följande som ett exempel:

Du kan instruera XML-tolken att analysera texten inom formatkoderna genom att helt enkelt ändra IGNORE till INCLUDE enligt följande:

Som vi nämnt tidigare kan du referera till en extern DTD i ett XML-dokuments DOCTYPE-deklaration så här:

Om du använder en DTD som har godkänts av en organisation såsom ISO (International Standards Organization), kan du använda ett PUBLIC-entitetsanrop som anger namnet på en offentligt tillgänglig DTD-kopia. När du gör det måste du dessutom ange URL för en SYSTEM DTD-fil, så det finns något att falla tillbaka på om den offentliga (PUBLIC) kopian av DTD inte finns tillgänglig.

Ibland kanske du skapar separata DTDer som definierar olika delar av ett dokument. Din organisation kanske t ex använder en DTD för alla sina XML-filers sidhuvud- och sidfotinformation, men olika DTDer för texten i dokumentet som framställes i olika delar av företaget. Du kan klara av sådana här situationer genom att helt enkelt skapa en enda ny DTD som inkluderar de olika DTDer som du behöver och anger en ordning för deras rotelement så här:

För dokument som skapas med denna DTD skulle <FSRapptDok> vara rotelementet, och <standardsidhuvud>, <FSRappt> och <standardsidfot> skulle vara dess omedelbara delelement. Ett dokument som använder denna DTD kan se ut så här:

Vissa arbetsflöden kan involvera DTDer som nästan är identiska för en grupp med användningsområden, men som kräver små justeringar för att fungera i någon viss avdelning eller grupp. Detta är enkelt att ordna; du inkluderar helt enkelt DTDn i DOCTYPE-deklarationen, lägg sedan till eventuella nödvändiga uppmärkningsdeklarationer i den interna delmängden.

Du kan inte omdefiniera ett element som redan är definierat i den externa DTDn, men du kan omdefiniera entiteter och standardvärden för attribut.

Om du skriver dina XML-dokument med hjälp av en ordbehandlare kan du läsa igenom motsvarande DTD och se till att du följer reglerna. Men du kommer inte att kunna vara riktigt säker på om du gjorde det eller ej förrän du validerar XML-dokumentet mot DTDn genom att använda ett program som kallas en validerande tolk. Denna validerande tolk läser DTDn och kontrollerar sedan din XML-fil för att garantera att den följer reglerna för den DTDn. En bra validerande tolk bör även tala om för dig vilka problem den eventuellt påträffar.

Kom ihåg att om du vill kontrollera att ett XML-dokument följer en viss DTD, behöver du en validerande XML-tolk, inte bara en normal XML-tolk. Det finns många XML-tolkar som kan tala om för dig huruvida en XML-fil är välutformad, men ansenligt färre som kan tala om för dig om en XML-fil är giltig.

För en snabbreferens till DTD-funktioner och -konventioner, se bilaga B, "DTD ­ Snabbreferens" i kapitel 7, "Bilagor".

Bör du utveckla en ny DTD som är specialdesignad så att den passar din organisations behov? Eller bör du använda en branschstandard-DTD som besparar dig utvecklingstid och hjälper till att garantera att du kan utbyta information med andra organisationer inom din bransch?

Det finns fördelar i båda tillvägagångssätten. Om du skapar din egen DTD från början har du total kontroll över DTD-strukturen och den process som krävs för att uppdatera den. Det fordras dock en hel del tid och ansträngning och du måste vara försiktig så att du tar hänsyn till behoven för alla som ska använda DTDn. Om du använder en branschstandard-DTD behöver du inte gå igenom DTD-utvecklingsprocessen, men du måste följa DTDns konventioner och följa den struktur som den definierar.

Om du avser att utbyta information med andra organisationer kan en branschstandard-DTD vara en bra idé. När du använder en branschstandard-DTD kan det hjälpa till att garantera att informationsutbytet sker utan problem och att den information som du formatkodar kan användas igen i andra sammanhang. Detta är faktiskt en av orsakerna till att XML utvecklades: att hjälpa till att standardisera formaten som information lagras och byts ut i.

Men att använda en branschstandard-DTD kan innebära andra utmaningar eftersom två organisationer kan ha mycket olika behov, även om de data de arbetar med i grund och botten är desamma. Branschstandard-DTDer kan modifieras för användning inom en organisation, men det omintetgör delvis deras syfte som är att garantera att information lagras i ett konsekvent format mellan olika organisationer.

Huruvida du kan använda en branschstandard-DTD beror på ett antal faktorer.

Finns det en branschstandard-DTD för din bransch?

Du kan få svaret på denna fråga genom att söka efter branschstandard-DTDer på webben. Två bra ställen att titta på är www.schema.net och www.xml.org.

Om det finns en branschstandard-DTD, uppfyller den dina behov?

• Om du hittar en branschstandard-DTD som verkar som om den kan fungera för din organisation, ska du noggrant gå igenom den innan du börjar använda den. Om du använder en olämplig DTD kan det leda till allvarliga problem. En olämplig DTD kan exempelvis:
• Tvinga författare att använda okända och olämpliga strukturer
• Kräva att författare tvingar in data i olämpliga element
• Begränsa författares förmåga att indexera och söka information
• Ge alltför mycket spelrum vilket kan leda till felaktig uppmärkning
• Försvåra konverteringar till andra format
• Tvinga program som behandlar data att bli överdrivet komplicerade
• Åsamka stora utgifter om det visar sig att DTDn i slutändan visar sig vara oanvändbar, vilket tvingar dig att konvertera alla dina data till ett annat format

Tänk noggrant över denna fråga; om den DTD som du väljer inte uppfyller dina behov kommer troligtvis den ackumulerade effekten av eventuella nackdelar att växa med tiden.

Om det inte finns någon branschstandard DTD för din bransch, finns det då någon under utveckling?

Om du inte kan hitta en branschstandard-DTD som passar dina organisationsmässiga behov kanske du vill ta reda på om det finns någon annan i din bransch som håller på att utveckla en sådan. Om så är fallet kanske din organisation kan få en chans att bidra med sin speciella expertis under utvecklingen av den DTDn. Deltagande i utvecklingen av en branschstandard-DTD kan hjälpa dig att undvika problem som kan bli resultatet om du måste anpassa en DTD som utvecklats av någon som inte förstår dina speciella problem.

Vissa organisationer väljer att använda en branschstandard-DTD, men modifierar den DTDn så att den passar deras speciella behov. När University of California Press t ex ville anpassa ISO-standarden SGML DTDn "book" till sina egna behov gjorde de en serie med justeringar i den. De lade t ex till element som gör det möjligt för dem att lagra sådan information som t ex kapitelunderrubriker och kapitelspecifika signaturer. ISO (International Standards Organization) tillhandahåller riktlinjer för modifiering av dess DTDer så att även om du gör sådana modifieringar blir din nya DTD ändå ganska standardiserad.

Vad händer om du behöver utbyta data med andra organisationer som använder den ursprungliga, ej modifierade DTDn? Vissa organisationer väljer att skapa verktyg som kan konvertera dokument som följer deras modifierade DTDer till dokument som följer DTDns ursprungliga form. Denna typ av lösning ger dig många av de fördelar du får genom att ha en anpassad DTD, men du får ändå möjlighet att utbyta data med andra organisationer i branschen.

Med hjälp av avenue.quark kan du använda en DTD till att extrahera strukturerat innehåll ur QuarkXPress-dokument och lagra det innehållet i filsystemet eller i en databas. I följande avsnitt beskriver vi hur processen fungerar genom att använda ett situationsexempel.

Låt oss säga att din organisation har skapat ett stort antal tekniska dokument i QuarkXPress-format och du skulle vilja exportera deras innehåll i XML-format och lagra det i en databas så att du kan göra det tillgängligt för dina kunder på webben. Alla dessa tekniska dokument använder samma mall och typografimallar från QuarkXPress.

Innan du kan extrahera det tekniska dokumentinnehållet i ett strukturerat format måste du ha en struktur för det innehållet. DTDn förser dig med den strukturen.

För mer om DTDer, se "Arbeta med DTDer" i detta kapitel.

Det finns två sätt att få en DTD som kan användas i avenue.quark:

• Välj en befintlig XML DTD. Det finns flera branschstandard-XML-DTDer tillgängliga nu och allteftersom XML används mer och mer, utvecklas fler och fler. Om du väljer att göra så här bör du noggrant tänka över vilken DTD du vill använda; en olämplig DTD kan göra det jobbigt för dem som behöver använda den.
• Utveckla din egen DTD. Läs "Arbeta med DTDer" i detta kapitel och analysera sedan noggrant de delar som ett tekniskt dokument består av och utveckla en motsvarande DTD. Denna process kan ta lång tid, men kommer att löna sig om den DTD som blir resultatet passar sitt ändamål. I allmänhet är det en redaktörs- eller administrationsgrupp som väljer en DTD.

Skapa ett nytt XML-dokument i avenue.quark och ange den DTD du valde i steg 1. Alla obligatoriska element i DTDn infogas automatiskt i XML-dokumentet.

Paletten XML-arbetsyta för ett nytt XML-dokument

En av avenue.quarks unika funktioner är regelbaserad formatkodning. Vid regelbaserad formatkodning skapar du en uppsättning med formatkodsregler som t ex instruerar avenue.quark att ett stycke som använder typografimallen "Rubrik" vanligtvis bör formatkodas som <Titel>. Du kan dessutom använda uppsättningar med formatkodningsregler till att ange hur speciella teckentypografimallar, textfärger och lokala formateringsstilar bör formatkodas. (För mer information om uppsättningar med formatkodningsregler, se kapitel 5, "Uppsättningar med formatkodningsregler".)

Spara XML-dokumentet som en mall som heter "TekDok.xmt". Mallen innehåller DTDn för tekniska dokument och den uppsättning med formatkodningsregler du skapade i steg 3. Du kan använda denna mall för att skapa önskat antal XML-filer med tekniska dokument på samma dator eller på flera datorer.

När du skapar ett nytt XML-dokument med avenue.quark, är det första du måste göra att välja en mall som du vill basera det nya XML-dokumentet på i listan Mall. För detta exempel använder vi "TekDok.xmt" från steg 4.

Mallen TekDok.xmt gör det lätt att formatkoda ett tekniskt dokument från QuarkXPress.

Om du vill utföra regelbaserad formatkodning, ska du COMMAND+dra (Mac OS) eller Ctrl+dra (Windows) den ruta som innehåller det tekniska dokumentet till <TekDok>-elementet i rullningslistan XML-träd. Avenue.quark formatkodar automatiskt dokumentet genom att använda reglerna som finns i uppsättningen med formatkodningsregler.

Om du vill använda regelbaserad formatkodning kan du helt enkelt COMMAND+dra (Mac OS) eller Ctrl+dra (Windows) rutan till lämpligt element i listan XML-träd. Avenue.quark använder uppsättningen med formatkodningsregler till att formatkoda så mycket av innehållet som möjligt.

När den regelbaserade formatkodningen har slutförts kan en del av dina tekniska dokument vara färdiga för leverans. Det kan dock hända att det finns ytterligare innehåll som behöver formatkodas manuellt eller förekomster av innehåll som kan formatkodas på fler än ett sätt. Du kan lösa sådana situationer genom att helt enkelt dra innehållet ifråga till tillämpligt element i paletten XML-arbetsyta.

När innehållet i det tekniska dokumentet är i XML-format kan du använda en rad olika verktyg för att placera det på webben. Du kan t ex servera det som rak XML och visa det genom att använda en nyare webbläsare såsom Microsoft Internet Explorer 5.0. XML-formatkodat innehåll kan också användas på många andra sätt, för allting från elektroniskt informationsutbyte till genereringen av tryckta dokument.